-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
enhance: broadcast with event-based notification #39522
enhance: broadcast with event-based notification #39522
Conversation
@chyezh E2e jenkins job failed, comment |
@chyezh go-sdk check failed, comment |
cd1b827
to
4877b2d
Compare
@chyezh E2e jenkins job failed, comment |
4877b2d
to
752ff02
Compare
@chyezh E2e jenkins job failed, comment |
- broadcast message can carry multi resource key now. - implement event-based notification for broadcast messages - broadcast message use broadcast id as a unique identifier in message - broadcasted message on vchannels keep the broadcasted vchannel now. - broadcasted message and broadcast message have a common broadcast header now. Signed-off-by: chyezh <[email protected]>
Signed-off-by: chyezh <[email protected]>
752ff02
to
d75e801
Compare
@chyezh E2e jenkins job failed, comment |
/run-cpu-e2e |
// We should always save the task after acked. | ||
// Even if the task mark as done in memory. | ||
// Because the task is set as done in memory before save the recovery info. | ||
return b.saveTask(ctx, b.Logger().With(zap.String("ackVChannel", vchannel))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should save the task state before updating its value in memory to avoid receiving a completed task state on the watch side if the persistence fails
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it.
Current behaviour make the watcher see the event done than event undone after the coord recovery.
It's ok because the consumer of broadcast message will acknowledge until success.
I will add a rollback logic if the save operation is failure in next PR to avoid it.
fix the unresolved issue in the next PR. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED Approval requirements bypassed by manually added approval. This pull-request has been approved by: chyezh The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
The implementation of this gRPC streaming watch mechanism is somewhat repetitive, suggesting to create a common watch function module in the future. |
issue: #38399 pr: #39522 - broadcast message can carry multi resource key now. - implement event-based notification for broadcast messages - broadcast message use broadcast id as a unique identifier in message - broadcasted message on vchannels keep the broadcasted vchannel now. - broadcasted message and broadcast message have a common broadcast header now. --------- Signed-off-by: chyezh <[email protected]>
issue: #38399